Method and system for enabling lay users to obtain relevant, personalized health related information

ABSTRACT

The invention features methods, systems, and computer programs for generating a customized set of possible medical conditions, thereby providing access to medical information relevant to the user&#39;s state of health. The methods and systems involve at least some of the following steps: receiving a list of symptoms specified in terms selected from a first language set; translating the list of symptoms into a translated list of symptoms specified in terms selected from a second language set; using the translated list of symptoms to generate possible medical conditions, the possible medical conditions described in terms of the second language set; and translating the possible medical conditions into descriptions that are specified in terms selected from the first language set.

RELATED APPLICATION

This application is a continuation of and claims priority to U.S. patentapplication Ser. No. 11/491,861 entitled “Method and System for EnablingLay Users to Obtain Relevant, Personalized Health Related Information”filed on Jul. 24, 2006, the entire contents of which are incorporated byreference herein.

BACKGROUND OF THE INVENTION

Consumer health information is growing in importance and popularity,with computer networks such as the Internet providing a growing share ofthe information. It is estimated that health issues are addressed attens of thousands of online sites with potentially millions of pages ofhealth or benefit-related works. Even more health related informationexists on networks available to medical professionals. Given the volumeand complexity of the available medical information, lay consumerswithout specific medical training are at a disadvantage and can haverelatively little success in finding desired or relevant informationamong such vast resources.

Moreover, given the extremely personal nature of health, mostindividuals have minimal interest in browsing materials that have norelevance to their health or the health of their families. Yet most ofthe health information accessible to the lay public exists onconventional network (e.g., Internet) sites or portals and addressesonly general topics. Such information seldom has any particularrelevance to individual users. Accordingly, there is a need for improvedsystems for obtaining relevant, personalized health related informationfrom computer networks such as the Internet.

SUMMARY OF THE INVENTION

In one aspect, the invention features methods, systems and computerprograms for generating a customized set of possible medical conditions.The methods and systems involve the steps of: receiving a list ofsymptoms specified in terms selected from a first language set;translating the list of symptoms into a translated list of symptomsspecified in terms selected from a second language set; using thetranslated list of symptoms to generate possible medical conditions, thepossible medical conditions described in terms of the second languageset; and translating the possible medical conditions into descriptionsthat are specified in terms selected from the first language set. Thegenerated possible medical conditions correspond to the translated listof symptoms.

In another aspect, the invention features methods, systems and computerprograms for generating input for a health condition query system. Themethods and systems involve the steps of: presenting a representation ofa human body to a user through a visual display; defining a plurality ofregions within the representation of the human body; receiving inputfrom the user selecting a particular one of the plurality of regions; inresponse to the received input, displaying to the user a list of healthsymptoms associated with the selected region; enabling the user toselect multiple symptoms from the displayed list of symptoms; andpresenting a list of possible medical conditions derived from theplurality of medical symptoms. In some implementations, the methods,systems and computer programs include enabling the user to select theorientation of the representation of the human body.

In another aspect, the invention features methods, systems and computerprograms for tracking possible medical conditions. This aspect involvesthe steps of: providing an interface to a query engine, which inresponse to receiving symptom information from a plurality of usersprovides a personalized list of possible diagnostic information to eachof the plurality of users; receiving input through the interface to thequery engine from each of the plurality of users, the input from eachuser comprising health symptom information and the geographic locationinformation; and analyzing the symptom information and the geographiclocation information for the plurality of users to determine medicalconditions as a function of geographic area.

In some implementations, the first language set is professional medicallanguage comprising professional medical terms that describe symptomsand conditions. Likewise, in some embodiments of the above aspects, thesecond language set is non-professional medical language, comprisingmedical terms used by laypeople to describe medical symptoms orconditions. In some implementations, the methods and systems alsoinvolve the steps of querying for additional symptom information basedon one or more of the following: one or more symptoms, one or morepossible medical conditions or one or more symptoms and one or morepossible medical conditions; and adding the additional symptominformation to the list of symptoms.

The methods, systems, and computer programs described herein are notmedical diagnostic systems and are not intended to take the place ofevaluation by a trained medical professional. Rather, these systems andmethods provide users access to medical information and help directusers to medical information that may be relevant to their state ofhealth.

The methods, systems, and computer programs described herein provide theadvantage of delivering relevant, customized health-related informationto consumers. The methods, systems, and computer programs provideconsumers access to expert, professional medical information systemswhich, due to vocabulary requirements, are not typically accessible tolaypeople without medical training. The methods, systems, and computerprograms also provide consumers an improved ability to identify detailedmedical information on a particular topic that is relevant to theirstate of health. Because identifying relevant medical informationrequires understanding the relationships between symptoms andconditions, this information is typically difficult for consumers who donot have medical training. The methods and systems also provide theability to analyze medical information taken directly from a largepopulation of users, thereby improving the immediacy and quality of theinformation.

The details of one or more embodiments described herein are set forth inthe accompanying drawings and the description below. Other features,objects, and advantages of the invention will be apparent from thedescription and drawings, as well as from the claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a flow diagram of one implementation of a health conditionquery system.

FIG. 2 is a flow diagram of one implementation of a health conditionquery system, in which information is exported to an external system.

FIG. 3 is a flow diagram of an output algorithm for a health conditionquery system.

FIG. 4 is a flow diagram of a symptom thesaurus algorithm.

FIG. 5 is a flow diagram of a user interface algorithm according to oneembodiment of the invention.

FIG. 6 is a flow diagram of a user interface algorithm in which queriesfor additional information.

FIG. 7 is a flow diagram for a medical information tracking system.

FIG. 8 is a flow diagram for a medical information tracking system inwhich symptom information is translated from a first language to asecond language.

FIG. 9 is an exemplary translated symptom list and possible medicalconditions list.

FIG. 10 is an exemplary clarification question interface.

FIG. 11 is an exemplary output interface.

FIGS. 12A and 12B are exemplary output for a medical informationtracking system in tabular format.

FIG. 13 is exemplary output for a medical information tracking system inpictorial format.

FIG. 14 is an exemplary clarification question interface.

FIG. 15 is a table with medical terms in professional andnon-professional language and associated concept-specific identifiers.

FIG. 16 is a table representing a data structure of relationshipsbetween conditions, symptoms, clarification questions, and other medicalinformation.

FIG. 17 is a block diagram of an implementation of a computer systemthat can be used on some of the embodiments of the invention.

FIG. 18 is an exemplary health condition query system interface.

FIG. 19 is an exemplary health condition query system interface showingresults for a search string.

FIG. 20 is an exemplary list of general medical symptoms.

FIG. 21 is an exemplary health condition query system interface with aclarification question.

FIG. 22 is an example of output for a health condition query system.

DETAILED DESCRIPTION

FIG. 1 is a flow diagram of a health condition query system 100 thatgenerates a list of possible medical conditions according to oneembodiment of the invention. The system collects health symptominformation from the user. It does this by presenting a graphical userinterface that solicits the relevant input. FIG. 18 is an example of auser interface for such a health condition query system. The user theninputs the information into the system (step 110). Referring to FIG. 18,in one implementation, the user inputs health symptom information byselecting from a list of possible symptoms for a given area of the body(1860). The system generates a list of selected symptoms (1880) based onthe user's input.

Health symptom information includes information about the user's stateof health, such as indications or manifestations of a physical conditionor disease. Nonlimiting examples of health symptom information includeheadache, sore throat, congestion, fever, cough, earache, nausea andmuscle cramp. The user expresses the health symptom information in termsselected from a first language set. One exemplary language set isnon-professional medical language. Non-professional medical languageincludes terms used by laypeople (i.e., people who do not have a medicaleducation) to describe a medical symptom or complaint. For example, alayperson may describe a symptom as headache, while the medicalprofessional term for that symptom is cephalgia. Accordingly, “headache”is considered a term selected from a non-professional language.

A translation engine translates the symptom list from the first languageset to a second language set (step 130). One exemplary language set isprofessional medical language, which includes terms used by medicalprofessionals (i.e., people with a medical education, such asphysicians, nurses, and mental health professionals). Professionallanguage includes terminology a medical professional would use todescribe medical symptoms or conditions. Such terms include those foundin medical dictionaries, thesauri, and encyclopedias. For example,“cephalgia” is a term selected from medical professional language forthe symptom “headache.” Translation proceeds through correlation ofconcept-specific identifiers that are associated with the health symptominformation in terms selected from both language sets. In the exampleabove, the concept-specific identifiers are associated with termsselected from non-professional language (step 115) and professionallanguage (step 125).

The association of concept-specific identifiers with health symptominformation is shown in steps 115 and 125. A symptom thesaurus algorithmassociates concept-specific identifiers with symptoms, such that eachsymptom expressed in non-professional language is uniquely associatedwith an identifier (step 115). Similarly, concept-specific identifiersare associated with health symptom information expressed in professionallanguage (step 125).

The thesaurus is stored on a computer-readable medium and provides theconcept-specific identifiers based upon the symptom or condition terms.The thesaurus incorporates terminology from many health-relatedvocabularies, including the Systematized Nomenclature of Medicine(SNOMED) promulgated by the College of American Pathologists; theInternational Classification of Diseases: 9th revision, ClinicalModification (ICD9), promulgated by the Health Care FinancingAdministration, as well as the Consumer Health Terminology® created byWellMed, Inc. (now WebMD, Inc.); and the Unified Medical Language System(UMLS®), promulgated by the U.S. National Library of Medicine, whichalso provides concept-specific identifiers.

The concept-specific identifiers are based on core medical concepts,enabling the thesaurus algorithm to map or associate multiple synonymsand related terms to the same concept-specific identifier or code. Forexample, “erythemia”, “hyperemic”, “injected”, “rugor”, and“erythematous” are all used in professional circles to describe the samething: redness or red-color. Similarly, “odynophagia” and “dysphagia”are both used to describe difficulty in swallowing. With respect toconditions, “hyperpiesis,” “elevated systolic pressure,” “high bloodpressure,” “hypertensive vascular disease” and “high blood” are all usedin consumer and professional circles to describe the same thing: highblood pressure. Accordingly, the thesaurus algorithm maps all theseterms with a single concept-specific identifier.

The concept-specific identifiers provide standardized identification ofthe health symptom information independent of traditional variationsbetween lay medical and clinical medical terminology for healthconditions. For example, the thesaurus algorithm associates the symptomchest pain with the concept-specific identifier: C0008031. It furthercorrelates the symptom with ICD9 code 786.50. Similarly, the thesaurusalgorithm associates abdominal pain with the concept specific identifierC0000737 and ICD9 code 789.00. As shown above, in one implementation,the concept-specific identifiers are in the form of alpha-numericsegments (e.g., 8 characters each). Alternatively, numeric or alphabeticsegments are used.

As part of generating a translated symptom list, the health conditionquery system also optionally collects additional personal healthinformation from the user (step 135). In some implementations, thesystem imports the personal health information from another resource,such as the user's stored profile or health record information that isstored in a computer-accessible manner (e.g., electronic health recordsstored at a physician site, electronic health records stored at aninsurance site and hospital admission records). Alternatively, thesystem presents input screens that solicit the desired information fromthe user. The personal health information includes further informationabout the user's state of health. The personal health informationincludes information that affects or has affected the health of the useror that is part of the user's health history. Exemplary personal healthinformation includes, without limitation, allergies. medical testinformation (e.g., blood tests, genetic tests and radiology consultreports), medications, health risks, vaccinations, surgeries orprocedures, known medical diagnoses, family history, past symptominformation, and past medical condition information generated from ahealth condition query system. The personal health information may alsoinclude demographic information about the user that is useful fordetermining possible medical conditions. Such information includes,without limitation, gender, age, and geographic location. The personalhealth information may also be correlated with concept-specificidentifiers. Referring to FIG. 18, the information includes the sex andage of the user (1830), which the user provides through an inputinterface (e.g., the “Start” tab (1820)).

In addition to additional personal health information, in someimplementations, the system collects health-related information fromexternal sources, such as information from public health organizations,such as the Centers for Disease Control (CDC). One nonlimiting exampleof such information includes CDC reports providing information abouthealth conditions occurring in particular areas. If this informationcorrelates with the geographic information provided by the user, it isincluded in the information used to generate the list of possiblemedical conditions. For example, if the CDC (or other public healthorganization), reports an increase in influenza in a particular area,the health condition query system will use that information whenconstructing the list of possible diagnoses for the user, if the user isalso located in the affected area. Similarly, other external healthinformation received by the health condition query system includesweather information that may affect medical conditions (e.g., downloadedfrom the National Weather Service or commercial services such asWeather.com) or information from a health condition tracking system suchas the tracking system described herein (e.g. FIGS. 7 and 8). In someimplementations, the health condition query system also translates theinformation from external sources (i.e., not generated from the user'sinput) from a first language to a second language as described above.

Once the health condition query system generates a translated symptomlist (step 130), the system generates possible medical conditions basedon those symptoms (step 140). Symptoms and possible conditions aremapped to one another in a database in a many to many relationship. Thesystem identifies possible conditions by correlation to one or moresymptoms.

In some implementations, the data is stored in the database as shown inFIG. 16. The possible medical conditions are generated in professionallanguage and are also associated with concept-specific identifiers (step145). For example, appendicitis is associated with concept-specificidentifier C0003615 and 1CD9 code 541, while cholecystitis isappendicitis is associated with concept-specific identifier C0008325 andICD9 code 575.10.

In some implementations, once the system generates an initial list ofpossible medical conditions, a clarification engine queries the user foradditional symptom information (step 170). The system presents thequeries to the user through a graphical user interface. In this process,the clarification engine includes a library of clarification questionsthat are mapped to particular conditions. When the health conditionquery system adds a possible condition to the list of possible medicalconditions, the clarification engine prompts the user for additionalinformation related to that condition. The system adds the additionalhealth symptom information to the symptom list, which is then used torefine the generated list of possible conditions. The library maps oneor more clarification questions to a particular condition or combinationof conditions. Generally, there is no restriction on the number ofclarification questions. In some specific implementations, one to fiveclarification questions are mapped to a condition. For example, theclarification engine links the condition “appendicitis” to one or moreclarification questions such as “Do you have a fever?” or “Do you havenausea?” or “Do you have vomiting?” The engine may also query the userfor additional information based on a combination of conditions andsymptoms. For example, if the health condition query system generatescholecystitis (inflammation of the gall bladder) as a possible conditionand the user has also included abdominal pain as a symptom, theclarification engine will ask the user: “Is you abdominal pain better orworse after meals?” If the answer is “worse”, the system either addsgallstones to the list of possible conditions or increases thelikelihood of that condition (e.g., increases its weight coefficient asdescribed below), as these are highly correlative. However, an answer of“better” or “no change” is neutral. In this case, the system may leavegallstones from the list of possible conditions, but not change thelikelihood of the condition. Alternatively, the system may removegallstones from the list of possible conditions or decrease thelikelihood of that condition (e.g., decreases its weight coefficient).

The clarification engine generates queries either at the time thecondition is identified as a possible condition or after the possibleconditions list is complete. While clarification questions are generallyoptional and the user may choose not to answer, in some implementations,the system does not add the possible condition to the conditions listuntil the user answers the clarification questions. Clarificationquestions are generally limited to general signs and symptoms that theuser can recognize without the need for a physician office visit.Clarification questions thus provide additional information upon whichsystem generates possible medical conditions. As more symptominformation is added and refined, the list of possible conditions ismore specific for the user's state of health.

The translation engine translates the possible medical conditions fromthe second language set to the first language set (e.g., fromprofessional language to non-professional language) (step 160) in aprocess similar to the process described above for the health symptominformation. Specifically, it associates concept specific identifierswith possible medical conditions in non-professional language. It thencorrelates concept-specific identifiers for each language to produce atranslated list of possible medical conditions in non-professionallanguage.

In some implementations, after translating the list of possibleconditions, the health condition query system assigns a weightcoefficient to each possible state of health (step 180). Weightcoefficients relate to the probability of one possible condition versusanother being applicable to the user's medical state (i.e., thelikelihood of that condition). The system derives weight coefficientsempirically, using information collected during the generation of thesymptom list and employing sets of rules stored in a database associatedwith the health condition query system. The rules take into account oneor more criteria for assigning weight coefficients. One criterion isclustering or pattern recognition of symptoms to possible conditions.For example, if a possible condition is associated with five symptoms,the system assigns a higher weight coefficient when the symptom listincludes four of the symptoms, compared to when it has just one of thesymptoms.

A second criterion for assigning weight coefficients is the specificityof a symptom or group of symptoms for a condition. Specificity is basedon population statistics of conditions and correlates with the frequencyof people having a particular symptom. For example, for a particularcondition, if a high percentage of people who are ultimately diagnosedwith the condition typically present with a specific symptom, thesymptom is considered highly specific for the condition. Accordingly,where these symptoms are present, the system assigns a higher weightcoefficient to these conditions. Alternatively, if only a few peoplediagnosed with the condition typically present with a particularsymptom, it is considered relatively non-specific and the system assignsa lower weight coefficient to the associated condition. In someimplementations, the system categorizes specificity levels for symptoms.For example, some symptoms are always correlated with a condition andare therefore highly specific. If a user presents with these symptoms,the system assigns the correlating condition a relatively high weightcoefficient. Other symptoms usually or typically occur with a particularcondition. Because these symptoms are less specific for the condition,the system assigns the condition a lower weight coefficient when thisclass of symptoms are the only symptoms present on the symptom list.Finally, some symptoms are only sometimes or infrequently correlatedwith a condition. When these are the only symptoms present for thecondition, the system assigns this condition the lowest weightcoefficient. Both specificity and clustering can also take into accountother medical information, such as age, gender, race, ethnic group andweight.

Another weighting criterion is based on exclusion symptoms. Exclusionsymptoms are symptoms that exclude a possible condition. For example, ifa user inputs “sore throat” and “cough”, one possible condition is strepthroat. If, however, through clarification questions, the user indicatesthat the cough is a productive cough, the weight coefficient for strepthroat is lowered (or the condition is even eliminated from the list),because productive coughing is not a symptom of strep throat; onlynon-productive coughs are a strep throat symptom.

In situations where a symptom is pathoneumonic for a possible condition(i.e., the symptom is 100% correlated with the condition), it may becategorized as a key or critical symptom. For example, a Fifth's diseaserash (a red rash on the cheek) is pathoneumonic, as is a Lyme's diseaserash (a bull's eye-shaped rash). Similarly, if a user indicates that hisleg is shortened and also rotates, these symptoms are pathoneumonic forfracture. When such symptoms are present, the system maximizes theweight coefficient maximized and, may, in some implementations,eliminate other, less specific, possible conditions from the list.

Other criteria for assigning weight coefficients include geographicallocation information (where conditions associated with a particulargeographical location are assigned a higher weight coefficient if theuser is also associated with that location), current medications(imported and self-reported), and information from external sources.External sources include reports from public health organizations,(e.g., CDC), weather related information, or information from a healthtracking system such as the condition tracking system described herein.The health condition query system assigns weight coefficients based onone or more of these criteria. For example, in one implementation, thesystem looks for clusters of symptoms, giving conditions that have moresymptoms present a higher coefficient. Next, the system examines thesymptom list for exclusion symptoms, to determine if any conditions canbe removed from the possible condition list (or its weight coefficientreduced) due to the presence of an exclusion symptom. Lastly, the systemevaluates the symptom list for specificity, increasing the weightcoefficient for conditions having multiple key symptoms and decreasingthe weight coefficient for conditions only presenting symptoms that areless specific (i.e., those that only sometimes correlate with thecondition). With regard to information collected from external sources,the system may increase a weight coefficient for the “influenza” if CDCreports indicate a rise in the incidence of influenza in California andthe user has indicated that she is experiencing coughing and is alsolocated in California. Similarly, if a user indicates she isexperiencing red eyes and sneezing and is located in Virginia, thehealth condition query system may download information from a healthtracking system (such as the condition tracking system described herein)that indicates an increase in the incidence of seasonal allergies in thesoutheast United States. In this situation, the health condition querysystem increases the weight coefficient for seasonal allergies.

In addition to weight coefficients for the likelihood of conditions, insome implementations, the system also assigns weight coefficients forthe acuity or urgency of the condition. Acuity or urgency is an estimateof how quickly a condition may manifest based on the information in thesymptom list. The urgency weight coefficient is separate from the weightcoefficient for the likelihood of the condition and, in someimplementations, the system may not alter the ordered list of possibleconditions based on the urgency weight coefficient. Instead, in someimplementations, the system alters the output of the list of possibleconditions to alert the user that a highly urgent or acute condition ispresent. For example, the system adds a marker or icon to conditionsassociated with highly urgent or acute conditions, based on the urgencyweight coefficient (e.g., the caution icon (1895) in FIG. 18).

In some implementations, the system also assigns weight coefficients forthe severity of the condition. Severity is an estimate of theseriousness of the condition or the extent of possible harm that mayresult from the condition. The severity weight coefficient is alsoseparate from the weight coefficient for the likelihood of thecondition. In some implementations, severity weight coefficient is alsoseparate from the urgency weight coefficient, while in someimplementations the system combines the severity and urgency weightcoefficients. As with the urgency coefficient, in some implementations,the system may not alter the ordered list of possible conditions basedon the severity weight coefficient. Instead, in some implementations.the system alters the output of the list of possible conditions to alertthe user that a severe condition is present. For example, the systemadds a marker or icon to conditions associated with severe conditions,based on the severity weight coefficient (e.g., the caution icon (1895)in FIG. 18). Similarly, when the system combines the urgency andseverity coefficients, it may use a single marker or icon to alert theuser that a severe and/or urgent condition is present. Externalinformation downloaded or otherwise received by the health conditionquery system may also be used to assign urgency and/or severitycoefficients.

Once the system assigns weight coefficients to the possible medicalconditions, it generates an ordered list of the possible conditions andoutputs the results (steps 190 and 200). An example of a list ofpossible conditions generated based on a user's selected symptominformation is shown in FIG. 18 (1890).

FIG. 2 is a flow diagram of a health condition query system 200 similarto system 100 in FIG. 1, in which an external system is used to generatethe list of possible conditions. System 200 begins as described abovefor process 100 (FIG. 1). The system collects health symptom informationand a translation engine translates the information fromnon-professional to professional language through correlation withconcept-specific identifiers (steps 210, 215, 225, and 230). The systemalso optionally collects additional personal health information to addto the symptom list (step 235). Health condition query system 200 thenexports the translated symptom list to an external system, whichgenerates a list of possible medical conditions (step 240). In someimplementations, the external system is a professional medical systemdesigned to accept professional medical information. Exemplaryprofessional systems include expert diagnostic systems, medical triagesystems, predictive modeling systems, health risk assessment systems,drug interaction checker systems, benefit or plan comparison tools,health cost estimator tools, and health cost financial planning tools.As such, the external system generates the possible medical conditionsin terms selected from professional language. The possible medicalconditions are also associated with concept-specific identifiers. Theexternal system then imports the possible medical conditions back tosystem 200 (step 250), which translates the conditions intonon-professional language according to a process described above forsystem 100 (step 260). In some implementations, the system assigns aweight coefficient (step 280), and generates an ordered list of possiblemedical conditions (step 290). Lastly, the system outputs the generatedpossible medical diagnostic information (step 295). By translatinghealth symptom information into professional language, system 200provides lay people the advantage of accessing professional informationand systems without requiring them to master the professional lexicon,which is often a prerequisite to using these systems.

FIG. 3 is a flow diagram of an output generator (300) that augmentshealth condition query systems 100 and 200 (FIGS. 1 and 2) by generatingoutput for the systems. As described above, health condition querysystems 100 and 200 generate a list of possible conditions in termsspecified in non-professional language (steps 190 and 290 of FIGS. 1 and2, respectively). The output generator begins with this information(step 310) and outputs the list of possible conditions in numerous ways.For example, in one implementation, a server creates and maintains oneor more user profiles and the output system adds the list of possiblemedical conditions to the user profile (step 320). The user profile canbe implemented as described in U.S. patent Publication No. 2006/0004607,which is incorporated by reference. The profile may contain informationcollected from the user, including symptoms, conditions, medications,test results, and demographic information. The user profile may alsocontain concept-specific identifiers associated with the information inthe user profile. The profile may be periodically updated to reflectactions taken by the user, including creating new symptom and conditionslists.

Once saved, the generator optionally delivers medical text informationto users on an automated basis using the saved symptom list information.For example, the output generator matches attributes (e.g.,health-related conditions) associated with the user with metadata (e.g.,concept-specific identifiers) associated with medical text informationloaded onto the server. As matches between the information in the user'sprofile and the metadata associated with the text information becomeavailable, the output generator automatically delivers the informationto the user. A health condition query system can also access theinformation stored in the user profile to generate additional possiblecondition lists, for example by combining the stored information withnew symptom information. For example, a user may create a symptom listthat includes numbness and tingling of the extremities. If the user'sstored profile information includes diabetes as a known medicaldiagnosis, is included in the algorithm and diabetic neuropathy will beadded to the list of possible conditions presented to the user, eventhough the user did not input this information as a medical symptomhimself. Thus, the health condition query system is able to provideusers with output that is relevant to their medical history, which isuseful where a user may not understand that current medical symptoms arerelevant to a previous diagnosis.

In another output option, output generator 300 presents a list ofpossible medical conditions directly to the user (step 330). FIG. 9 isan example of a possible condition list (910) presented through agraphical user interface. As shown in FIG. 9, in some implementations,the output system categorizes the list of possible conditions based onthe severity of the conditions and presents the results in a tabularformat. Similarly, FIG. 18 depicts a list of possible conditions (1890)correlating to the selected symptoms (1880) of sore throat, taste ofacid in mouth, and choking.

After presenting the list of possible medical conditions to the user,the output generator then invites the user to select a particularmedical condition that the user desires more information (step 340)through hyperlinks in a graphical user interface. Based on thisselection, the generator provides medical treatment information innon-professional language to the user (step 370). Output generator 300provides this information by correlating the concept-specificidentifiers for the possible medical conditions with concept-specificidentifiers that have been previously associated with medical treatmentinformation (steps 350 and 360). The medical information includeswithout limitation a general overview of the medical condition,indication of symptoms, and treatment options. FIG. 11 is an example ofoutput provided to the user for strep throat. FIG. 22 is an example ofoutput provided to the user for heartburn. As shown in FIG. 22, uponselecting the “View Conditions” tab (2210), the user is presented withthe list of possible symptoms correlating to his or her condition(2220). In the example of FIG. 22, when the user selects “heartburn”,system provides various information about the health-related condition(2230). As shown in FIG. 22, the health-related information contentincludes, without limitation overview, pictures, video, and articles.Treatment options available as output with generator 300 include,without limitation, indications used to treat the condition, informationabout physicians who typically treat the condition, and cost estimatesfor one or more treatment plans (e.g., based on local and/or nationalaverages). The output generator can further access the user's medicalbenefit information (step 380) to provide customized treatmentinformation to the user (step 390). For example, the medical benefitinformation can include physician referral information. By accessing theuser's medical benefit information the generator determines thephysician network to which the user belongs or to which the user hasaccess through his or her health plan. The generator then correlatesthat information with the selected health-related condition, andprovides a list of all doctors within the user's network who treat theselected health-related condition. Similarly, the output generator canaccess the user's insurance benefit information to provide a customizedreport of expected treatment costs (both out-of-pocket costs and totalcosts for both the patient and the insurer), contracted benefitinformation, and a listing of medications on the user's health planformulary (including a comparison with all medications available fortreatment) for the condition. As with the list of possible medicalconditions, the personalized treatment information can also be saved tothe user's profile (step 395).

FIG. 5 is a flow diagram of the operation of an input generator for ahealth condition query system. Exemplary health condition query systemsused with the process of FIG. 5 are the systems described above, asshown in FIGS. 2 and 3. The input generators provide three modes forgenerating input, as shown in steps 510, 530, and 550.

In step 510, a human body representation is presented to a user via acomputer display. FIG. 18 is a representative interface for a healthcondition query system showing a human body representation according tostep 510 (1810 of FIG. 18). In some implementations, the generatorinvites the user to select a specific human body representation (e.g.,unisex, male or female). In the example of FIG. 18. a malerepresentation has been selected by selecting the appropriate choiceunder the “Start” tab (1820). The user can alter this choice by clickingon the “EDIT” button (1830). After the selected human bodyrepresentation is presented, the generator invites the user to select abody region (step 520). In the example of FIG. 18, the body region ishighlighted as the user moves the cursor over it or clicks on it. Thebody region selection correlates with the area or zones of the body inwhich the user is experiencing a medical symptom or complaint. Forexample, if the user is experiencing sore throat, the user selects theneck or throat region. Similarly, if the user is experiencing nausea,the user selects the stomach or abdomen region. Body regions availablefor selection are any isolatable surface of the body. Generally, bodyregions available for selection are those that are associated withparticular symptoms. Nonlimiting examples of body regions include: heador scalp, face, neck, throat, chest, breast, abdomen, shoulder, arm,elbow, hand, wrist, fingers, groin, genital region, hip, thigh, knee,leg, ankle, buttocks, back, foot and toes. These body regions may bepresented for selection individually or as a group. For example, hand,wrist and fingers may be grouped into one region corresponding to thelower arm, while shoulder, arm and elbow are grouped into one regioncorresponding to the upper arm. Similarly, leg and ankle can be groupedinto one region corresponding to the lower leg, while hip and thigh aregrouped into one region corresponding to the upper leg. Likewise, theface region can include eyes, ears, nose and mouth or these regions canbe selected separately. While the examples provided above are externalbody regions, internal body regions, such as organs or muscles, are alsowithin the scope of the invention.

Also, in some implementations, the generator solicits the user to selectan orientation for the body representation (e.g., front or back) (1840in FIG. 18). If the user chooses an orientation, only body regionslocated in that orientation are available for selection. For example, ifthe back orientation is chosen, buttocks and back are shown, but chestor breast is not.

Step 530 provides another option for generating input for a healthcondition query system. In step 530, the generator invites the user toenter search terms by providing a search string input field on the userinterface. (1850 in FIG. 18) The user provides the search term byentering it into a designated search field. The search term correspondsto a keyword. Keywords are matched to symptoms in a many to manyfashion.

Once the user selects a body region (step 520) or a search term (step530), the generator displays a list of potential symptoms correspondingto the selection or search term (step 540) (1860 in FIG. 18). When inputgenerator 500 is used to generate input for a health condition querysystem (e.g., 100 or 200), the generator displays symptom information interms selected from non-professional language. When the user hasselected a particular body region (step 520), the generator onlypresents only symptoms associated with that region. For example, if theuser selects the abdomen region, the generator presents symptoms such asnausea, cramps, and gas, but does not present symptoms such as headache,shoulder pain or ankle pain because they are not associated with theabdomen region. As shown in FIG. 18, symptoms relating to the Chest Areaare presented (1860). FIG. 19 is another view of the interface of FIG.18 in which “headache” is entered as a search term (1950) and thegenerator displays a list of symptoms that match one or more of thekeywords entered (1960 in FIG. 19). In some implementations, thegenerator presents only symptoms that contain all the keywords. Forexample, if “chronic head pain” is entered, the generator returns onlysymptoms with that exact name. Alternatively, the generator displays alist of symptoms that contain any of the entered keywords. In step 530,the generator searches all symptoms available, whether or not they arelinked to a particular body region.

Step 550 provides another option for generating input for a healthcondition query system. In step 550, the generator presents a list orsymptoms that are not specific to a particular body region to the user.In FIG. 18, the generator presents the non-specific symptoms in responseto the user selecting the “General Symptoms” tab of the interface(1870). A representative list of general symptoms that would appearunder the “General Symptoms” tab is provided in FIG. 20. Such symptomsinclude, without limitation, symptoms that affect the entire body ratherthan a specific region. Nonlimiting examples of such symptoms aresymptoms related to the skin, fever, general body ache, faintness,vertigo, fatigue, and excessive sweating.

Once symptom information is presented through steps 540 or 550, thegenerator invites the user to select one or more symptoms (step 560).The user selects symptoms corresponding to his or her present state ofhealth from the lists that correspond to one of the input methods (steps510, 530, or 550). For example, when symptoms that correspond to aselected body region are displayed, the user selects one or more of thesymptoms and the symptoms are added to a symptom list (step 570). In theexample of FIG. 18, the user selects one or more symptoms from thepossible symptom list (1860) by clicking on the symptom. Once the userselects the symptom, it is entered into the “Selected Symptoms” list(1880). In some implementations, the user selects symptoms from multiplezones. For example, as shown in FIG. 18, the user has selected symptomsfrom the chest region. If the user is also experiencing headache, theuser selects or clicks on the head region and chooses “headache” fromthe list of possible symptoms. The generator adds “Headache” to theselected symptom list, along with the chest-related symptoms already onthe list.

After the user selects one or more symptoms, the health condition querysystem presents a list of possible medical conditions derived from theselected medical symptoms (570). The health condition query systemgenerates the list of possible medical conditions by analyzing all ofthe medical symptoms selected by the user. Exemplary methods forderiving possible medical conditions include one or more embodimentsdescribed herein. In some embodiments, generation of the healthcondition query system is dynamic—as symptoms are selected, possiblemedical conditions are generated and the list of possible medicalconditions is updated as more symptoms are added or as the generatorreceived additional information through clarification questions.

FIG. 6 is another input generator for a health condition query system.The generator of FIG. 6 is similar to the generator of FIG. 5, with theaddition of a clarification algorithm that refines the symptom list forthe user's specific health complaints (steps 670-680). Steps 610-660proceed as described above for steps 510-560 of FIG. 5. The generatorinvites the user to select symptoms from a list of potential symptomscorresponding to a selected body region, a search term, or a list ofnon-region specific symptoms and added to a symptom list. In step 670,the clarification algorithm queries for additional health symptominformation. The clarification algorithm is similar to the clarificationengine associated with health condition query system 100 (FIG. 1, step170), except that clarification questions are mapped to symptoms ratherthan conditions or combinations of conditions. Thus, when the userselects a symptom, the algorithm prompts the user for additionalinformation relating to that symptom. One or more clarificationquestions are mapped to a particular symptom or combination of symptoms.Generally, there is no restriction on the number of clarificationquestions. In some implementations, one to five clarification questionsare used. For example, the symptom “headache” is linked to one or moreclarification questions such as “did the headache start suddenly?” or“have you suffered a head injury lately?” FIG. 21 is an example of auser interface showing one of a series of four clarification questions(2110) in response to the symptom “Sore Throat.” FIG. 10 is an exampleof a query for additional information in response to the symptom“shoulder pain.” Similarly, FIG. 14 is an example of a query foradditional information in response to the symptom “chest pain.” Finally,FIG. 16 shows how clarification questions are linked to particularsymptoms and also linked to conditions. For example, the clarificationengine links the symptom “swollen glands” to the clarification question“Both sides or just one?”, which is in turn mapped to the condition“strep throat”. Similar clarification questions relate to cough andheadache symptoms.

The algorithm user queries with clarification questions either at thetime the symptom is selected or after the symptom list is complete. Insome implementations, the algorithm does not add the symptom to thesymptom list until the user has answered the clarification questions.

Additional symptom information is collected as the user answers thequeries for additional information (step 680). The user answers thequestions by selecting the appropriate response for his or her state ofhealth. The algorithm then adds the additional symptom information tothe symptom list (step 660). For example, if the user selects “yes” forthe clarification question “did the headache start suddenly?”, thatinformation is added to the symptom list. Similarly, if the user selects“no”. the negative information is also added to the symptom list. If theuser does not answer the question, or selects “don't know”, however, noinformation is added to the symptom list, as the answer does not furtherrefine the symptom information. In some implementations, the systemrequires the user to provide an answer to the clarification question.Thus, clarification questions thus provide additional information uponwhich the possible medical conditions are generated.

As with the input generator described with regard to FIG. 5, as the userselects one or more symptoms, the health condition query system presentsa list of possible medical conditions derived from the selected medicalsymptoms (690).

As described above, the translation engines employ the concept-specificidentifiers and corresponding symptom or condition terms that togethermay form a health terminology thesaurus. Exemplary concept-specificidentifiers and corresponding symptom, condition or health informationare shown in FIG. 15. The relationships between each concept-specificidentifier and the corresponding symptom, condition or healthinformation are stored in a data structure that is in turn stored inlocal or remote memory or storage and includes a concept-specificidentifier (e.g., alphanumeric) and one or more associated symptom orcondition terms (or health information terms). The relationshipinformation stored in the data structure provides uniform identificationof symptom or condition concepts despite a variety or lay medical termsand professional medical terms being in use. The listing or concepts inFIG. 15 is not exhaustive of the symptom or condition terms to which theconcept-specific identifiers may be applied. To improve search of andaccess to medical information relating to symptoms and conditions, inone implementation, the concepts (i.e., symptoms, conditions, and otherhealth information) are organized based on their taxonomic and/orsemantic relationships, as described in U.S. patent Publication No.2006/0004607, which is incorporated in its entirety.

FIG. 4 is a flow diagram of algorithm for creating a symptom thesaurus,400. The algorithm 400 first develops a universal list of health symptominformation (step 410). The algorithm develops the universal list interminology selected from a professional language. Next, the algorithmoptionally correlates body regions to the health symptom information(step 420). For example, nausea and indigestion are correlated with theabdominal region, while itchy eyes and runny nose are correlated withthe head or facial region. The algorithm then associates each instanceof medical symptom information with a concept-specific identifier (step430). Finally, the algorithm translates the medical symptoms into termsselected from non-professional language by mapping the concept-specificidentifiers to symptoms in non-professional language (step 430). Forexample, nausea and indigestion are translated to “dyspepsia”, whileitchy eyes and runny nose are translated to “rhinorrhea”.

The concept-specific identifiers also allow the symptom thesaurus tomanage synonyms for medical symptoms. Often, many different terms areused by laypeople to describe the same medical symptom. For example,diabetes is sometimes referred to as saccharine diabetes, sugar disease,sugar sickness, or low blood sugar. In some cases, synonyms are regionalin nature (e.g., regional colloquialisms), while some synonyms reflectdifferent vernacular or consumer terms. For example, swelling of thefeet is referred to as “dropsy” in some areas and back pain is sometimesreferred to as lumbago. Associating the same concept-specific identifierto each of these synonymous terms provides for correlation to the properterm for the symptom in professional language. Thus, the algorithmgenerates a thesaurus, or library, of medical symptoms associated withconcept-specific identifiers. The thesaurus may to be used by a healthcondition query system (e.g., steps 115 or 125 of system 100), either byselecting a symptom in non-professional language or by selecting asymptom in professional language.

FIG. 7 is a flow diagram of a condition tracking system (700) thatanalyzes medical information collected from users of the healthcondition query systems (e.g., 100 or 200) described above. The systempools the information from users and collectively analyzes it todetermine population-wide trends. By linking the user-suppliedinformation to a geographic locator, the system can provide informationabout the local prevalence and geographic distribution of user-reportedsystems and related conditions. Symptom clusters or condition clustersthat are tracked using system 700 include contagious diseases (e.g.,anthrax, SARS, bird flu, cold, flu, mumps, and measles) as well asconditions that are cyclical or location-specific (e.g., seasonalallergies, Valley fever (coccidiomycosis), and Lyme's disease).

The condition tracking system provides users an interface to a queryengine (step 710). Exemplary interfaces used by the system 700 includeinput generators 500 and 600, described in FIGS. 5 and 6 and also theinterface example of FIG. 18. Through the interface, the system receivesmedical information from multiple users (steps 730 a, 730 b, 730 c). Themedical information includes symptom information and other healthinformation, as well as geographic location information (e.g., a zipcode, city and/or state, or country). Alternatively, the medicalinformation includes the date and/or time the information was received.In response to receiving symptom information, a health condition querysystem generates a personalized list of possible medical diagnosticinformation for each user (step 720). Exemplary health condition querysystems include systems 100 and 200 (FIGS. 1 and 2). The system linkspersonal medical information and the geographic location information andsaves it for further analysis (step 740). The information is savedlocally or remotely. In some implementations, the linked medicalgeographic location information are saved in user profiles on a server.The system then analyzes the saved symptom information and geographiclocation information (step 750) on a population-wide basis (i.e., from aplurality of users) and determines medical conditions as a function ofgeographic area (step 760). The analysis involves identifying clustersof symptoms or conditions in the stored user-supplied information. Forexample, the system can analyze information to determine the number ofusers concurrently reporting one or more symptoms that are typical forinfluenza (e.g., fever, sore throat, muscle ache, headache or fatigue)in specific geographic areas (FIG. 12A)). To assess the emergence,location and/or prevalence of a possible avian influenza outbreak, thesystem analyzes the stored medical information for the number of usersconcurrently reporting influenza symptoms as well as one or moreatypical symptoms (e.g., conjunctivitis (eye infection), breathingproblems (e.g., pneumonia, acute respiratory distress, viral pneumonia),chest pain, diarrhea, or confusion (without breathing problems)) (FIG.12B). Alternatively, the system analyzes the information to determinegeographic areas having the highest incidence of certain symptoms (FIG.13). The analysis becomes more specific for particular conditions as theinformation is scrutinized for multiple symptoms associated with acondition.

FIG. 8 is flow diagram of another condition tracking system (800) inwhich the health symptom information is translated from a first languageto a second language (e.g., non-professional to professional language).The system receives medical information from users and then translatesit from non-professional to professional language (steps 840 a, 840 b,and 840 c). The translation engine makes use of concept-specificidentifiers associated with medical information in either language type,similar to the translation engines described above (FIGS. 2 and 3).

System 800 presents an interface to a health condition query system(step 810). As with system 700, exemplary interfaces used in system 800include those described in FIGS. 5 and 6 (systems 500 and 600,respectively). Through the interface, the system receives medicalinformation (from a plurality of users) in non-professional language(steps 820 a, 820 b, 820 c). The information includes a geographiclocator. The medical information is associated with concept-specificidentifiers (step 830). The system translates the information innon-professional language to professional language by correlating theconcept-specific identifiers in non-professional language withconcept-specific identifiers associated to medical information inprofessional language (steps 840 a, 840 b, 840 c and 850). In responseto receiving the information, the health condition query systemgenerates a personalized list of possible medical diagnostic informationfor each user (step 860). Exemplary health condition query systemsinclude systems 100 and 200 (FIGS. 1 and 2). The condition trackingsystem links the personal medical information and the geographiclocation information together and saves for further analysis (step 870),as described above. The system then analyzes the saved symptominformation and geographic location information are then analyzed (step880) on a population-wide basis and determines possible medicalconditions as a function of geographic area (step 890). As above forsystem 700, the analysis involves identifying clusters of symptoms orconditions in the stored user-supplied information. System 800 includesanalysis of translated information, as well as including the associatedconcept-specific identifiers in the analysis.

The condition tracking systems generate in tabular format (FIGS. 12A and12B), graphical format, or a pictorial format suitable for marketing orpublication use (e.g., FIG. 13). Public health officials can use outputfrom processes 700 and 800 to determine the incidence of possiblemedical conditions by geographical area. Besides determining the spreadof contagious diseases systems 700 and 800 allow for regionalcomparisons of various conditions (e.g., prevalence of symptoms orconditions in different cities). For example, the systems can report ordisplay the occurrence of heartburn in New York City versus Chicago.These systems are also useful for providing geographically based medicalinformation directly to consumers, for example through condition reportsor condition maps. Such reports and maps can be located on a websiteaccessible to a user or reported through the media.

The above described systems and algorithms generate personalized healthinformation via a computer network. FIG. 17 is a conceptual diagram ofone implementation of the systems and algorithms used in conjunctionwith the various embodiments described herein. In some implementations,one more users provide input (1730 a-c), which a remote system (1720)then processes. In some implementations, the system is a web-basedapplication and the user provides input through a web browser. The useris commonly a lay individual without specific medical training. Thecomputer network (1740) may be private or public and may be a directconnection, a local area network or wide area network, a wirelessnetwork or an intranet. In one implementation, possible medicalconditions are provided to the user over the Internet. The remote system(1720) is a server or a remote computer, which includes a processingunit (1750), and, optionally one or more databases (1770 a-c) and one ormore user profiles (1760 a-c). As described herein, the user inputshealth symptom information through an input device (1730 a-c), such as apersonal computer, a workstation, or a server terminal. The systemtransmits the information through the computer network (i.e., over theInternet) to the remote system (1702), which then translates the symptominformation to professional language and generates possible medicalconditions using databases installed directly on the remote system (1770a-c) or an external system (1780). In some implementations, the systemcollects additional medical information located in the user's profile(1760 a-c), which is stored on the remote system. In someimplementations, the user profiles are stored remotely, for example on aseparate server or computer, in which case the system imports theinformation from the separate system. As described above, the systemsprovide output to the user by conventional means such as through ascreen or by hard copy. The input and output information can be savelocally or remotely, including in a user profile.

Other Embodiments

Other embodiments are also within the scope of the invention. While theembodiments presented above illustrate how the invention can be used togenerate customized medical information it is understood that thesystems and methods of the invention are not limited to the specificembodiments described above. Moreover, while the methods and systems aredescribed in terms of medical information, they are not limited to thisapplication, but rather can be applied to any situation where a firstset of concepts are used to generate a second set of concepts.

Although translation is described above in terms of translating medicalinformation in professional terms to non-professional terms, the systemscan be used to translate concepts between any two languages (i.e., froma first language to a second language). Similarly, symptom and conditionthesauruses are not limited to the terminologies and vocabulary sourcesdescribed above.

As indicated above, the health condition query systems are not limitedto systems incorporating a clarification engine. Similarly, in someimplementations the symptom check system does not collect and addpersonal health information to a symptom list. Moreover, systems withinthe scope of this invention may not generate an ordered list of possibleconditions based on weight coefficients. While the query interfacedescribed above is described in terms of a human body representation, itis understood that this method is applicable to any type of animalphysiology.

While the systems and algorithms presented here are described as systemsin which a user provides input, the systems and algorithms are notlimited solely to applications in which a user supplies input. Forexample, health symptom information or additional health information canbe provided through networks or data downloads from other systemscontaining information useful for generating possible medicalconditions. Moreover, the systems and algorithms can be used in otherapplications and environments, such as in a system for questioningpatients for medical information, or in a system for collecting triageinformation about a patient. In these systems, a user or someone in theposition of evaluating a patient may supply the information.

It is to be understood that while the invention has been described inconjunction with the detailed description thereof, the foregoingdescription is intended to illustrate and not limit the scope of theinvention. Other aspects, advantages, and modifications are within thescope of the following claims. Furthermore, it will be recognizedembodiments can be modified in arrangement and detail without departingfrom the principles of the invention. It should be understood that theprograms, processes, or methods described herein are not related orlimited to any particular type of computer apparatus, unless indicatedotherwise.

What is claimed:
 1. A computer system for generating a diagnosis based on identified symptoms associated with a patient, the system having a computer configured to execute instructions stored on a memory, said system comprising: an interface configured to receive one or more symptoms associated with the patient; an analysis module configured to generate possible medical conditions based on the one or more symptoms associated with the patient; and an assignor configured to assign a probability weight coefficient to each of the possible medical conditions based on a presence of one or more symptoms that exclude a possible condition and at least one of (i) clustering or pattern recognition of symptoms to possible conditions, and (ii) whether the patient is associated with a geographical location that is also associated with at least one of the possible medical conditions; wherein the analysis module is also configured to generate an ordered list of possible medical conditions associated with the patient based on the assigned weight coefficients.
 2. The system of claim 2, wherein the interface comprises a representation of a human body presented to a user through a visual display, wherein a plurality of regions are defined within the representation of the human body; the interface is configured to receive input from the user selecting a particular one of the plurality of regions; the interface is configured to display to the user a list of symptoms associated with the selected region and is configured to enable the user to select the one or more symptoms associated with the patient from the displayed list of symptoms; and the interface is also configured to display the ordered list of possible medical conditions associated with the patient.
 3. The system of claim 3, wherein the interface is further configured to: query the user for additional symptom information to refine the possible medical conditions generated by the analysis module; receive the additional symptom information from the user; and add the additional symptom information to the one or more symptoms selected by the user.
 4. The system of claim 1, wherein the interface is further configured to receive additional personal health information, and wherein the analysis module is configured to generate the possible medical conditions based on the additional personal health information as well as the one or more symptoms associated with the patient.
 5. The system of claim 4, wherein the additional personal health information is at least one of age, gender, and geographical information.
 6. The system of claim 1, wherein the interface is further configured to: query for additional symptom information to refine the possible medical conditions generated by the analysis module; receive the additional symptom information; and add the received additional symptom information to the one or more symptoms associated with the patient.
 7. The system of claim 1, wherein the interface is configured to receive the one or more symptoms associated with the patient from at least one of user input and an external data source.
 8. The system of claim 7, wherein the external data source is at least one of a health profile associated with the patient, public health information, and a health tracking system.
 9. A computer-implemented method for generating a diagnosis based on identified symptoms associated with a patient, said method comprising: in a computer system, receiving one or more symptoms associated with the patient; based on the one or more symptoms, in the computer system, generating possible medical conditions; assigning a probability weight coefficient to each of the possible medical conditions based on a presence of one or more symptoms that exclude a possible condition and at least one of (i) clustering or pattern recognition of symptoms to possible conditions, and (ii) whether the patient is associated with a geographical location that is also associated with at least one of the possible medical conditions; and generating an ordered list of possible medical conditions associated with the patient based on the assigned weight coefficients.
 10. The method of claim 9, wherein the one or more symptoms are received by a method comprising: via the computer system presenting a representation of a human body to a user through a visual display; defining a plurality of regions within the representation of the human body; via the computer system receiving input from the user selecting a particular one of the plurality of regions; in response to the received input, displaying to the user a list of symptoms associated with the selected region; and enabling the user to select the one or more symptoms associated with the patient from the displayed list of symptoms.
 11. The method of claim 10, further comprising: querying the user for additional symptom information to refine the generated possible medical conditions; receiving the additional symptom information from the user; and adding the additional symptom information to the one or more symptoms selected by the user.
 12. The method of claim 9, further comprising receiving additional personal health information and wherein generating the possible medical conditions is also based on the personal health information.
 13. The method of claim 12, wherein the additional personal health information is at least one of age, gender, and geographical information.
 14. The method of claim 9, further comprising: via the computer system, querying for additional symptom information to refine the generated possible medical conditions; receiving the additional symptom information; and adding the received additional symptom information to the one or more symptoms associated with the patient.
 15. The method of claim 9, wherein the received list of symptoms is received from at least one of user input and an external data source.
 16. The method of claim 15, wherein the external data source is at least one of a health profile associated with the patient, public health information, and a health tracking system.
 17. A computer system for determining population-wide health trends, the system having a computer configured to execute instructions stored on a memory, the system comprising: an interface to a query engine configured to receive, for each user of a plurality of users, (i) a list of reported symptoms and (ii) a geographic location; an analysis module configured to generate possible medical conditions for each user of the plurality of users based on the list of reported symptoms received from said each user of the plurality of users; and a cluster identification module configured to identify at least one of symptom clusters and condition clusters based on a number of users concurrently reporting one or more symptoms associated with a specific medical condition at specific geographic locations.
 18. The system of claim 17, wherein the identification of at least one of symptom clusters and condition clusters is based on identifying geographic locations having a highest incidence of one or more specific symptoms.
 19. The system of claim 17, further comprising: an assignment module configured to assign, for each user, a probability weight coefficient to each of the possible medical conditions generated for said each user based on a presence of one or more symptoms that exclude a possible condition and at least one of (i) clustering or pattern recognition of symptoms to possible conditions, and (ii) whether said each user is associated with a geographical location that is also associated with at least one of the possible medical conditions.
 20. The system of claim 17, further comprising a comparison module configured to compare prevalence of at least one of reported symptoms and generated medical conditions in different geographic locations.
 21. The system of claim 17, wherein the cluster identification module provides information related to the identified at least one of symptom clusters and condition clusters to the plurality of users via a website having at least one of condition reports and condition maps.
 22. The system of claim 17, further comprising an output module configured to provide an output to a third party, wherein the output includes at least one of (i) a comparison of a prevalence of at least one of symptoms and conditions in different geographical locations, and (ii) an identification of a geographical location having a highest incidence of one or more specific symptoms; and wherein the output is in a format suitable for marketing or publication use.
 23. The system of claim 22, wherein the third party is at least one of a public health official, a marketer, and a consumer.
 24. The system of claim 17, wherein the interface comprises a visual display having a representation of a human body, wherein the visual display defines a plurality of regions within the representation of the human body; the interface is configured to receive input selecting a particular one of the plurality of regions; and the interface is configured to display a list of medical symptoms associated with the selected region via the visual display and is configured to enable selection of a plurality of symptoms from the displayed list of symptoms.
 25. A computer-implemented method for determining population-wide health trends, the method comprising: receiving, for each user of a plurality of users, via an interface to a query engine in a computer system, (i) a list of reported symptoms and (ii) a geographic location; generating, in the computer system, possible medical conditions for each user of the plurality of users based on the list of reported symptoms received from said each user of the plurality of users; and identifying, in the computer system, at least one of symptom clusters and condition clusters based on a number of users concurrently reporting one or more symptoms associated with a specific medical condition at specific geographic locations.
 26. The method of claim 25, wherein the identification of at least one of symptom clusters and condition clusters is based on identifying geographic locations having a highest incidence of one or more specific symptoms.
 27. The method of claim 25, further comprising: assigning, for each user, a probability weight coefficient to each of the possible medical conditions generated for said each user based on a presence of one or more symptoms that exclude a possible condition and at least one of (i) clustering or pattern recognition of symptoms to possible conditions, and (ii) whether said each user is associated with a geographical location that is also associated with at least one of the possible medical conditions.
 28. The method of claim 25, further comprising comparing prevalence of at least one of symptoms and conditions in different geographic locations.
 29. The method of claim 25, further comprising providing information related to the identified at least one of symptom clusters and condition clusters to the plurality of users via a website having at least one of condition reports and condition maps.
 30. The method of claim 25, further comprising providing an output to a third party, wherein the output includes at least one of (i) a comparison of a prevalence of at least one of symptoms and conditions in different geographical locations, and (ii) an identification of a geographical location having a highest incidence of one or more specific symptoms; and wherein the output is in a format suitable for marketing or publication use.
 31. The method of claim 30, wherein the third party is at least one of a public health official, a marketer, and a consumer.
 32. The method of claim 25, wherein the list of reported symptoms received for each user of the plurality of users is received by a method comprising: presenting a representation of a human body through a visual display; defining a plurality of regions within the representation of the human body; receiving input selecting a first region of the plurality of regions; in response to the received input, displaying a list of medical symptoms associated with the selected first region; and enabling selection of a plurality of symptoms from the displayed list of symptoms.
 33. A non-transitory computer-readable medium storing code for execution on a computer system, said code comprising instructions that, when executed by the computer system, cause the computer system to: receive one or more symptoms associated with a patient; based on the one or more symptoms, generate possible medical conditions; assign a probability weight coefficient to each of the possible medical conditions based on a presence of one or more symptoms that exclude a possible condition and at least one of (i) clustering or pattern recognition of symptoms to possible conditions; and (ii) whether the patient is associated with a geographical location that is also associated with at least one of the possible medical conditions; and generate an ordered list of possible medical conditions associated with the patient based on the assigned weight coefficients.
 34. A non-transitory computer-readable medium storing code for execution on a computer system, said code comprising instructions that, when executed by the computer system, cause the computer system to: receive, for each user of a plurality of users, in a computer system, (i) a list of reported symptoms and (ii) a geographic location; generate, in the computer system, possible medical conditions for each user of the plurality of users based on the list of reported symptoms received from said each user of the plurality of users; and identify, in the computer system, at least one of symptom clusters and condition clusters based on a number of users concurrently reporting one or more symptoms associated with a specific medical condition at specific geographic locations. 